Tcpフロー制御のための方法及び装置
专利摘要:
通信エンティティは、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の伝送制御プロトコル(TCP)通信をサポートするための高レーテンシ通信リンクの一端に配置される。通信エンティティは、受信セグメントを検査するよう構成されたプロキシ・ロジックを備え、受信セグメントがデータを含んでいないということの識別に応じて、プロキシ・ロジックは、複数の同期化セグメント及び検査された受信セグメントに基づいて少なくとも1つの肯定応答メッセージを局所に生成するようにプロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にする。 公开号:JP2011515032A 申请号:JP2010545445 申请日:2009-02-03 公开日:2011-05-12 发明作者:スペイト,ティモシー,ジェームス 申请人:アイピーワイヤレス,インコーポレイテッド; IPC主号:H04L12-56
专利说明:
[0001] 本発明は、TCP(伝送制御プロトコル)フロー制御に関し、特に、無線通信システムにおけるフロー制御(これに限定される訳でない)に関する。] 背景技術 [0002] 伝送制御プロトコル(TCP)は、周知のTCP/IP(インターネット・プロトコル)通信プロトコル群におけるプロトコルである(TCPプロトコル全体の説明については、RFC793を参照されたい)。TCPは、コネクション指向の、高信頼度のバイト・ストリーム・サービスを提供するものであり、元々、非常に低い誤り率を有する有線ネットワーク用に企図されている。] [0003] TCPは、送出側が送信する、肯定応答されていないデータの量を制限するウインドウ・ベースのフロー制御機構を動作させる。この制限は、輻輳ウィンドウ(cwnd)及び共用宣言されたウインドウ(awnd)の最小値に基づく。輻輳ウィンドウは、TCPデータの送出側によって制御され、周知の遅い開始及び輻輳回避機構に基づく。遅い開始は、TCPフローの開始におけるシステム内の肯定応答されていないデータの量をゆっくり増加させる役目を担い、輻輳回避は、欠落パケットが検出されると、システム内の肯定応答されていないデータの量を半分にし、次いで、その通常のフロー・レベルまでもう一度、肯定応答されていないデータをゆっくりと増加させる。awndは、より多くのデータを処理する受信器の機能に基づいて制御される。「awnd」の初期値は、TCPプロトコル・スタックにおいて構成されたパラメータによって制御される。] [0004] 上述のように、TCPは、低い誤り率のネットワーク用に企図されている。したがって、TCPベースの通信ネットワークにおいて生じるパケット喪失は何れも、ネットワーク輻輳によるものとされ、したがって、「cwnd」、及び上述の送出側のデータ・レートにおける削減が続く。] [0005] しかし、このことは、固有に高い誤り率のシステムである無線ネットワークには適切でない。したがって、第3世代パートナーシップ・プロジェクト(3GPP)標準は、エア・インタフェースを介した伝送の結果として誤りを受ける、データ・パケットを再送信することを可能にする、(3GPP技術仕様3GPP TS25.322記載の)無線リンク制御(RLC)として知られる自動再送要求(ARQ)機能を提供する。データ・パケット配信の信頼度は、所定のトリガに応答して、RLC送信側エンティティにもう一度、RLC受信側エンティティによって送出されるRLC肯定応答メッセージ(ACK)の使用によって維持される。トリガは例えば、パケットを喪失した旨の検出時の、又は、特定数の受信パケットの受信時のタイマに基づき得る。このようにして、喪失したか、又は損なわれたデータ・セグメント若しくはデータ・パケットは送信器に示すことができ、前述の喪失したか、又は損なわれたデータ・セグメント若しくはデータ・パケットは再送出することができる。更に、(HSDPA及びE−DCHをサポートする)3GPPの後のバージョンでは、更なる再送信手法が、周知のOSIプロトコルのレイヤ1(L1)層及び媒体アクセス制御(MAC)層にあるハイブリッド自動要求(HARQ)機能によって提供される。] [0006] しかし、ARQ(及びHARQ)手法の使用により、データ・バケットが、誤った順序で到着する。よって、データ・パケットは、TCP処理に渡される前にバッファリングされなければならない。バッファリングの使用は、遅延の増加をもたらし、これは、RTT(往復時間)の増加をもたらし得る。] [0007] 3GPP標準グループによって規定されているロングターム・エボリューション(LTE)や競合するWiMax通信標準などの多くの無線データ・システムは、非常に大きなエア・インタフェース・スループットを有する一方、高いレーテンシを有する。よって、通常の無線システムを介したTCPの動作により、重大な問題が生じる。例えば、高レーテンシにより、TCPレートが高エア・インタフェース・スループットを駆使するには相対的に長い時間がかかり、遅い開始が実行されていても、通信リンクはよって、十分活用されていない。このことは特に、比較的小さなオブジェクト毎に複数のTCPコネクションが開けられる際に(例えば、モバイル・ユーザがウェブ・ブラウジングを行っている際に)問題である。] [0008] 大半のパソコン(PC)TCPスタックに使用される通常の「awnd」値は、低い(8192バイト程度)である。これは、「awnd」が修正されない限り、高レーテンシ無線システムにおける通信リンクを完全に利用することが決して可能でないということを意味している。通常、「awnd」値は、リンクの帯域幅遅延積に設定される。しかし、これは、下り(DL)方向における(すなわち、ネットワークからエンドユーザへの)TCPデータ・フローについてエア・インタフェースが完全に駆使されることを可能にする手段を提供するに過ぎない。上り(UL)(すなわち、移動ユーザ(又は固定ユーザ)からネットワークまで)では、「awnd」は、ネットワーク内のサーバによって規定され、明らかに、同様なやり方でこれを変えるとは可能でない。したがって、一層高いULレートが達成可能になるにつれ、UL TCPレートは多くの場合、一般的なエア・インタフェース条件でなく、サーバ「awnd」によって制限される。] [0009] 高レーテンシ無線システムにおいて単にawndを増加させることに関連した更なる問題点は、コア・ネットワークにおける輻輳による喪失データ・パケットにより、DL TCPレートが悪影響を受け、高い関連レーテンシにより、回復に長い時間がかかることになるという点である。上述の通り、高データ・レートの高遅延エア・インタフェース通信リンクを完全に利用するために非常に大きなawnd値(例えば、「100000」程度の「awnd」値)を使用することが有益である。喪失データ・パケットが生じると、「cwnd」はこの値の半分に削減される。この半分にされた値は通常、通信リンクを完全に利用するには十分でなく、よって、観察されるスループットは削減される。] [0010] よって、単に「awnd」を増加させるのは、高レーテンシ無線システムにおけるTCP性能には、受け入れ可能な解決策でない。] [0011] 次に図1を参照すれば、TCPデータ・フロー100の既知の機構を示す。TCPデータ・フロー100が、パーソナル・コンピュータ(PC)105と、携帯電話機などのユーザ機器(UE)110と、無線アクセス・ネットワーク(RAN)115と、通信サーバ120との間で構成される。既知の機構では、TCPACKがエア・インタフェースを介して送出される。上述の通り、通常のTCPネットワークは更に、UE110とRAN115との間の無線ネットワークを介した、無線リンク制御(PLC)層通信130及びハイブリッド自動再送要求(HARQ)135を使用し得る。] 図1 [0012] エア・インタフェースを介して送出されるTCP肯定応答メッセージ(TCPACK)が概ね不必要であり、単に、貴重なエアインタフェース・リソースの浪費であるということを本願の発明者は認識し、理解している。これは、下にあるRLC及びHARQ再送手法(ACKメッセージ自体も使用する)により、エア・インタフェースにおける損失が補正され、それにより、TCPの再送信機能が冗長になり、よって、TCP ACKをエア・インタフェースを介して送出しなくてもよくなるということが確実にされるからである。図1に示すように、TCPデータ・パケットについて、3つのレベルのデータ・フロー制御/再送信機能が存在しており、これは最適以下とみなされる。] 図1 [0013] 次に図2を参照すれば、無線システムを介したTCPの使用に関連付けられた問題点の一部を軽減するTCPアーキテクチャ200を示す。TCPデータ・フローが、パソコン(PC)205と、携帯電話機などのユーザ機器(UE)210と、無線アクセス・ネットワーク(RAN)215と、通信サーバ220との間で構成される。TCPネットワーク・アーキテクチャは、UE210とRAN215との間の無線ネットワークを介して、無線リンク制御(RLC)層通信230及びハイブリッド自動再送要求(HARQ)235を使用する。] 図2 [0014] 特に、このアーキテクチャは、TCPプロキシ機能を行うUE210及びRAN215にロジックを組み入れることにより、エンドツーエンドTCPコネクションを除去する。この結果、RLCバッファがオーバフローすることがないということを確実にするために、特定の形態のフロー制御がTCPプロキシにおいて存在していることが必要である。] [0015] エンドツーエンドTCP機能が除去されるので、この場合、IP及びTCPヘッダがプロキシで完全に除去されることが可能であり、パケットの下にあるパケット部分のみ、並びにRLC及びMACに関連付けられたヘッダがUuインタフェースを介して送信される。受信側プロキシは次いで、システムのこの端部において存在するTCPコネクションの状態に適切なTCPヘッダを追加する。] [0016] 図2におけるTCPネットワーク・アーキテクチャ200において使用される機能を明らかにするために、例示的なデータ・フローを以下に検討する。非常に大きなファイルのファイル転送プロトコル(FTP)ダウンロードが開始された場合に、RAN215におけるTCPプロキシ・ロジックにフロー制御機能がない場合、潜在的には、FTPファイル全体を、RAN215内のRNCRLCバッファに記憶する必要がある。よって、送信側RLCエンティティにおける利用可能なバッファ占有量に基づいて「awnd」が制御されることを可能にするフロー制御の特定の手法が、TCPプロキシにおいて必要である。これは、通知される「awnd」値を求めるためにバッファ占有量の単一の尺度が使用される既知の構成で限定的に扱われる。] 図2 [0017] 既知のアーキテクチャにおける、このシナリオの潜在的な問題点は、接続を維持している間に、RLC受信ウィンドウ移動(MRW)コマンド又はリセットが生じ得るという点である。RLC MRWコマンドは、送信側エンティティが、RLCプロトコル・データ・ユニット(PDU)の送出をあきらめ、受信器が、RLC−SDUを構成するRLC PDU 全てをスキップするようにそのウィンドウを順方向に移動させなければならない。この場合、TCPフロー制御は、喪失デ—タ・セグメントの再送信が行われ得る最終手段を先行して提供している。上にあるTCPプロトコルなしでは、前述の再送信は行われない。更に、UE端部及びネットワーク端部においてTCPコネクションが完全に別個であるので、前述の問題を解消するために更なる再送信手法を提供することは困難である。] [0018] 更に、エンドツーエンドTCP機能なしのフローでは、UEがセルを変わる際に、潜在的な問題が、PC側及びネットワーク側において別々の(すなわち、非同期の)TCPセッションが行われているということによって生じ得る。 次に図3を参照すれば、既知の3ウェイ・ハンドシェイク処理を使用したデータ・フロー制御プロトコル・アーキテクチャ300を示す。3ウェイ・ハンドシェイク310は、通常のものとして(すなわち、RLC/MAC/L1を使用して)RANプロトコル・スタックを介して送出される。これは、図2に表すように、完全な非エンドツーエンドの通常の機能の場合と異なる。図2では、別個の2つの3ウェイ・ハンドシェイクが、3ウェイ・ハンドシェイクがエア・インタフェースを介して行われないネットワーク側プロキシ、サーバ、プロキシ、ユーザPC及びUE側間で行われる。] 図2 図3 [0019] 3ウェイ・ハンドシェイクがエンドツーエンドで使用されるので、その場合、事実上、「同期化されている」エア・インタフェースの何れの側でもTCPプロキシを使用することが可能である。よって、TCPプロトコルは、通信リンクのエア・インタフェース部分を介して実行されないが、サーバ及びクライアントの視点から、接続が実際にエンドツーエンドであると思われる。] 発明が解決しようとする課題 [0020] よって、(特に、セルラ無線通信ネットワークを介した)TCPデータ・フローという課題に対処するための改良された機構が効果的である。] 課題を解決するための手段 [0021] 本発明の第1の局面によれば、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一方端にある通信エンティティが提供される。通信エンティティは、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の伝送制御プロトコル(TCP)通信をサポートするよう構成される。通信エンティティは、受信セグメントを検査するよう構成されたプロキシ・ロジックを備え、受信セグメントがデータを含んでいないということの識別に応じて、プロキシ・ロジックは、複数の同期化セグメント及び検査された受信セグメントに基づいて少なくとも1つの肯定応答メッセージを局所に生成するようにプロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することを可能にする。] [0022] 本発明の局面は、例えば、エア・インタフェースを介して肯定応答(ACK)又は否定応答(NACK)同期化メッセージを送受信する必要なく、エア・インタフェースの両方の端をプロキシ・ロジックが同期化させることを可能にすることにより、通信システムにおける通信リソースの改良された使用を可能にし得る。 本発明の局面は、例えば、データ再送信の数を削減することにより、エンドユーザによって認識されたものとして、改良された性能を可能にし得る。本発明の局面は例えば、削減された数の再送信により、増加したスループット・レートを提供し得る。] [0023] 本発明の任意的な構成では、プロキシ・ロジックは、後に受信されたセグメントがデータを含む場合に再同期化を行うよう更に構成され得る。再同期化は、後に受信されたセグメントに含まれるシーケンス番号に基づく。] [0024] 本発明の任意の構成によれば、プロキシ・ロジックは、データを含まない何れかの後に受信されたセグメントを却下するよう更に構成される。] [0025] 本発明の任意的な構成によれば、プロキシ・ロジックは、受信ウィンドウ移動(MRW)及びリセットのうちの少なくとも一方が生じた時点を求めることにより、データ・セグメントの喪失を識別するよう構成された無線リンク制御(RLC)ロジックを更に備える。本発明の任意的な構成によれば、RLCロジックは、この喪失をプロキシ・ロジック/機能に通知し得る。このようにして、標準的なRLC機能を、既存のMRW及びリセット・コマンドの形態で使用することができる。標準機能は、プロキシ・ロジックへの前述のコマンドの通知を可能にすることによって拡張される。] [0026] 本発明の任意的な構成によれば、無線リンク制御ロジックは、データ・セグメント全てがRLC肯定応答(ACK)されている旨をRLCロジックがバッファ・ロジックに示すまでバッファ・ロジックが受信データ・セグメントを記憶するようにバッファ・ロジックに、動作可能に結合し得る。このようにして、無線リンク制御ロジックは、RLCが例えば、MRW又はリセット・コマンドを出した旨をプロキシ・ロジックが識別することを可能にする。よって、プロキシ・ロジックは、これに関連付けられたTCPセグメントを再送信することができる。] [0027] このようにして、無線リンク制御層メッセージを検査することにより、喪失パケットの高速再送信を、再送信についてTCPに依存するのでなく、達成することができる。] [0028] 本発明の任意的な構成によれば、バッファ・ロジックは、RLCロジックからの表示に応じてそのバッファからの肯定応答データを廃棄し得る。] [0029] 通信エンティティが、高レーテンシ通信リンクの受信側にある場合、RLCロジックは、データ・セグメントのシーケンス番号全てが首尾良く受信されている訳でない場合に、再送信する対象の欠落データを要求し得る。] [0030] 本発明の任意的な構成によれば、通信エンティティが高レーテンシ通信リンクの送信側にある場合、RLCロジックは、高レーテンシ通信リンクを介して送出される少なくとも1つのデータ・セグメントが肯定応答されていないことを識別することができる。それに応じて、RLCロジックは、バッファ・ロジックからの肯定応答されていないRLCデータ・セグメントの再送信を開始し得る。] [0031] 本発明の任意的な構成によれば、同期化情報は、3ウェイ・ハンドシェイクを含み得る。例えば、3ウェイ・ハンドシェイクは、少なくとも、同期化表示、同期化肯定応答表示、及び肯定応答表示のうちの1つを含み得る。] [0032] 本発明の任意的な構成によれば、プロキシ・ロジックは、送信バッファ・ロジック及び受信バッファ・ロジックを含み得る。送信バッファ・ロジック及び受信バッファ・ロジックは、送信エンティティと受信エンティティとの間の通信エンティティを介してトランスペアレントに通過する同期化セグメント内の、シーケンス番号(SEQ)、肯定応答(ACK)番号、ウィンドウ・スケーリング、選択的な肯定応答、及びタイムスタンプのうちの少なくとも1つのメンテナンスを観察するよう構成され得る。] [0033] 本発明の任意的な構成によれば、プロキシ・ロジックは、受信エンティティによって生成されるTCPACKを検査し、ACKがデータを含まないか否かを判定するよう構成され得る。TCP ACKがデータを含まないことをプロキシ・ロジックが判定した場合、プロキシ・ロジックが、TCP ACKを、終結し得、エア・インタフェースを介してTCP ACKを送出しないということがあり得る。] [0034] 本発明の任意的な構成によれば、プロキシ・ロジックは、受信エンティティが、送信されるセグメントを受信する前に、TCPACKを送信エンティティにもう一度送信するよう構成し得る。] [0035] 本発明の任意的な構成によれば、通信エンティティは、第3世代パートナーシップ・プロジェクト(3GPP)データ通信システムを介してTCP通信をサポートするよう構成されたユーザ機器(UE)及びネットワーク・エンティティの一方であり得る。] [0036] 本発明の第2の局面によれば、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一方端にある通信エンティティにおける伝送制御プロトコル(TCP)通信をサポートするためのプロキシ・ロジックが提供される。プロキシ・ロジックは、受信セグメントを検査するよう構成されたロジックを備え、受信セグメントがデータを含まないということの識別に応じて、プロキシ・ロジックは、プロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にし、複数の同期化セグメント、及び検査された受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージを生成する、 本発明の第3の局面によれば、データ通信システムにおける第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一方端にある通信エンティティによる伝送制御プロトコル(TCP)通信を提供する方法が提供される。上記方法は、TCPプロキシ・ロジックにより、受信セグメントを検査する工程と、受信セグメントがデータを含まない旨の判定に応じて、プロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にする工程とを含む。方法は、プロキシ・ロジックにより、複数の同期化セグメント及び検査された受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージをプロキシ・ロジックによって局所で生成する工程を更に含む。] [0037] 本発明の第4の局面によれば、データ通信システムにおける第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一方端にある通信エンティティによる伝送制御プロトコル(TCP)通信をサポートするためのコンピュータ・コードを含むコンピュータ・プログラム・プロダクトが提供される。上記コンピュータ・プログラム・プロダクトは、TCPプロキシ・ロジックにより、受信セグメントを検査し、受信セグメントがデータを含まない旨の判定に応じて、プロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にするためのプログラム・コードを含む。コンピュータ・プログラム・プロダクトは、プロキシ・ロジックにより、複数の同期化セグメント及び検査された受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージをプロキシ・ロジックによって局所で生成するためのプログラム・コードを更に含む。] [0038] 本発明の第5の局面によれば、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の伝送制御プロトコル(TCP)通信をサポートし、高レーテンシ通信リンクの一方端にある通信エンティティを備えるデータ通信システムが提供される。データ通信システムは、通信エンティティに配置され、受信セグメントを検査するよう構成されたプロキシ・ロジックを備え、受信セグメントがデータを含んでいないということの識別に応じて、プロキシ・ロジックは、複数の同期化セグメント及び検査された受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージを局所に生成するようにプロキシ・ロジックを介して第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にする。] 図面の簡単な説明 [0039] 既知のTCPフロー制御プロトコル・アーキテクチャを示す図である。 既知のデータ・フロー制御プロトコル・アーキテクチャを示す図である。 3ウェイ・ハンドシェイク処理を使用した既知のデータ・フロー制御プロトコル・アーキテクチャを示す図である。 本発明の実施例をサポートするよう適合された無線セルラ通信ネットワークを示す図である。 本発明の実施例によるTCPプロトコル・アクセラレータのデータ・フロー制御プロトコル・アーキテクチャを示す図である。 本発明の実施例による、TCPプロトコル・アクセラレータ・フロー制御を示す図である。 本発明の実施例による、両方の同期化TCPプロキシにおいて使用されるバッファ・ロジック機能を示す図である。 本発明の実施例による、同期化TCPプロキシの送受信側において使用されるバッファ・ロジック機能を示す図である。 セグメントがコア・ネットワークにおいて失われた場合の、プロトコル・アクセラレータの動作の例を示す図である。 本発明の実施例による、セグメントがRANにおいて失われた場合のプロトコル・アクセラレータの動作の例を示す図である。 本発明の実施例による、セグメントがUEプロキシとクライアントとの間において失われた場合のプロトコル・アクセラレータの動作の例を示す図である。 本発明の実施例における処理機能を実現するよう使用することができる通常のコンピューティング・システムを示す図である。] [0040] 本発明の前述及び他の局面は、後述する実施例を参照すると、明らかであり、明らかにされるであろう。] [0041] 本発明の実施例によれば、前述の課題は、RAN及びUEにおいて「同期化する」TCPプロキシを提供することによって軽減される。特に、本発明の意味合いでは、ハンドシェイク処理(、例えば、既知の3ウェイ・ハンドシェイク)及びデータを含む何れかのセグメントは、「同期化」TCPプロキシ・ロジックを「トランスペアレントに通過する」ことが可能になる。すなわち、それらは、何れにせよ修正されず、(少なくとも、後述する実施例では、)無線アクセス・ネットワークの低位層に続くことが可能にされ、最終的に、受信側プロキシ・ロジックで受信され、ここではやはり、修正なしでプロキシ・ロジックを通過する。] [0042] まず図4を参照すれば、UMTS無線アクセス・ネットワーク(UTRAN)システム400は、端末/ユーザ機器ドメイン410と、UMTS地上無線アクセス・ネットワーク・ドメイン420と、インフラストラクチャ・ドメイン430とを含むと、好都合にみなされる。] 図4 [0043] 端末/ユーザ機器ドメイン410では、端末機器(TE)412は、有線又は無線Rインタフェースを介して移動機器(ME)414に接続される。ME414は、ユーザ・サービス識別情報モジュール(USIM)416にも接続される。ME414及びUSIM416は併せて、ユーザ機器(UE)418とみなされる。UE418は例えば、遠隔装置、移動局、通信端末、又は携帯情報端末であり得る。UE418は、ラップトップ・コンピュータ、又は組み込み型の通信プロセッサに結合し得る。] [0044] UE418は、無線Uuインタフェースを介して無線アクセス・ネットワーク・ドメイン420においてノードB422(基地局として動作するための機能要素及びロジックを実質的に含む)とパケット・データを通信する。無線アクセス・ネットワーク・ドメイン420内では、ノードB422は、無線ネットワーク制御装置(RNC)424とIubインタフェースを介して通信する。RNC424は、他のRNC(図示せず)と、Iurインタフェースを介して通信する。] [0045] ノードB422及びRNC424は併せて、UTRAN426を形成する。RNC424は、処理するGPRSサービス・ノード(SGSN)432とコア・ネットワーク・ドメイン430においてIuインタフェースを介して通信する。コア・ネットワーク・ドメイン430内では、SGSN432は、Gnインタフェースを介してゲートウェイGPRSサポート・ノードGGSN434と通信する。GGSN434は、公衆データ・ネットワーク438とGiインタフェースを介して通信する。] [0046] よって、構成要素であるRNC424、SGSN432及びGGSN434は、図4に示すように、無線アクセス・ネットワーク・ドメイン420とコア・ネットワーク・ドメイン430との間で分けられる、分離した別個の装置として(それぞれ自身のソフトウェア/ハードウェアのプラットフォーム上で)通常、提供されている。] 図4 [0047] RNC424は、数多くのノードB422のリソースの制御及び割り当ての役割を果たすUTRANエレメントである。通常、50乃至100のノードBを1つのRNCによって制御することができる。RNCは更に、エア・インタフェースを介してユーザ・トラフィックを高精度で配信する。RNCは互いにIurインタフェースを介して通信する。SGSN432は、セッション制御の役割を果たすUMTSコア・ネットワーク・エレメントである。SGSN432は、個々のUE418の位置を把握し、セキュリティ機能及びアクセス制御を行う。SGSN432は、多くのRNCに対する大容量の集中制御装置である。GGSN434は、コア・パケット・ネットワーク内のユーザ・データを最終的な宛先(例えば、インターネット・サービス・プロバイダ(ISP))に集中させ、トネリングする役割を果たすUMTSコア・ネットワークの構成要素である。端末機器(TE)412(パソコン(PC)など)は、有線インタフェース又は無線Rインタフェースを介して移動機器(ME)414に接続され得る。ME414は、ユーザ・サービス識別情報モジュール(USIM)416にも接続される。ME414及びUSIM416は併せて、ユーザ機器(UE)418とみなされる。] [0048] 前述のUTRANシステム及びその動作は、www.3gpp.orgの3GPPウェブサイトから入手可能な、3rd Generation Partnership Projectの技術仕様文書(3GPP TS45.401、3GPP TS43.060)及び関連文書に、より詳細に記載されており、本明細書では更に詳細に説明しない。] [0049] 本発明の一実施例によれば、図4のアーキテクチャが、Uuエア・インタフェースの両側にTCPプロキシ・ロジック及び機能が存在することをサポートするよう適合され、それにより、Uuエア・インタフェースにわたってTCPプロトコルが施されなくなる。よって、本発明の一実施例では、RNC224及びUE218は、図5乃至図11に関して後述するようなプロキシTCPロジックを備えるよう適合されている。別の実施例では、例えば、3GPPロング・ターム・エボリューション(LTE)システムにおける実現に対し、プロキシTCPロジックが、拡張eノードBに存在し得る。他のシステムでは、プロキシTCPロジックが他の構成要素において存在し得、したがって、本発明の概念は、本明細書及び特許請求の範囲記載の特定の構成要素に制限されない。] 図11 図4 図5 [0050] 次に図5を参照すれば、TCPプロトコル・アクセラレータの更なるデータ・フロー制御プロトコル・アーキテクチャを本発明の実施例によって示す。UE510及びRNC315における同期化TCPプロキシは、既知の3ウェイ・ハンドシェイク(「SYN」542、「SYNACK」544及び「ACK」546)が、PC505と、例えば、ウェブ・サーバ520との間のエンドツーエンド通信のためにトランスペアレントに通過することを可能にするよう構成される。] 図5 [0051] よって、前述の「同期化」TCPメッセージ内に含まれる情報は次いで、TCP通信における「ACK」及び「SEQ」フィールドを同期化させるために使用されるので、UE510及びRNC515におけるTCPプロキシは、全体のTCPコネクションのエンドポイントからのものであるようにみえる(例えば、エンドツーエンドであるようにみえる)TCP ACK(及びNACK)を生成することができる。既知の3ウェイ・ハンドシェイク540、542、544には図5において、例えば、ウェブ・サーバ520からPC505への下り(DL)シナリオにおける、データ・セグメント546の転送が続く。] 図5 [0052] 更に、プロキシの同期化機能は、選択的肯定応答(RFC1072におけるSACK)及びウィンドウ・スケーリング(RFC793)などのネゴシエートTCP機能の3ウェイ・ハンドシェイクの検査に拡張される。後述するように、プロキシが局所ACKを生成すると、その場合、これらに応じられる。] [0053] 図5に示すように、ネットワーク側556及びUE側555におけるプロキシ機能は、3ウェイ・ハンドシェイク540、542及び546がプロキシを介して直接通過することを可能にする(データを含まない場合も)。なお、データを含む他のセグメントについてはこのことはあてはまらない)。この例では、ダウンロードが行われ、第1のTCPセグメントがウェブ・サーバ546から送出されると、ネットワーク側及びUE側でプロキシを介して直接通過する。図3に表す通常のTCPプロキシ機能と違って、TCP/IPヘッダは除去されない(図3のTCPは、エア・インタフェースの両側で完全に終結される)。一例では、当業者が分かるように、TCP/IPヘッダを圧縮することができる。] 図3 図5 [0054] 3ウェイ・ハンドシェイクがプロキシを通過すると、プロキシは次いで、生成される何れかのその後のTCPACKが、3ウェイ・ハンドシェイクでネゴシエートされた適切なSEQ番号を使用することを確実にすることができる。更に、ウィンドウ・スケーリング、選択的な肯定応答等などの何れかのネゴシエートされたオプションも、プロキシからACKを生成する場合に、考慮に入れなければならないことがあり得る。このようにして、当業者は、プロキシ・ロジックをこの場合、「同期化プロキシ」とみなし得る。] [0055] ネットワーク側のプロキシは、「同期化プロキシ」を介してデータ・セグメント546を可能にし次第、TCPACK552をサーバに戻す。ACKは、完全に機能するTCPスタックがACKを取り扱うやり方と同様に戻される。よって、図5では、ネットワーク550におけるTCPプロキシによって生成されるACKの内容は、PC550によって生成されるものとほぼ、ちょうど同じである。] 図5 [0056] ACKの内容における考えられる差は、(後述する)awnd、タイムスタンプ・フィールド(このTCPオプションがイネーブルされた場合)、及び最後に、チェックサム(TCPのコンテンツ全体の積)である。よって、「awnd」が異なる場合、チェックサムは異なる。このようにして、プロキシは、「早期ACK」として通常知られるものを生成する。しかし、これらは、適切に同期化されているので、システムはなお、エンドツーエンド特性を有しているようにみえる。] [0057] PC550によって生成されるTCPACKがUE端におけるプロキシにおいて検査され、データが含まれていない(すなわち、TCP ACK のみである)と判定されるので、終結させ、エア・インタフェースを介して送出されない(ネットワーク端におけるプロキシは既に工程552でデータ・セグメント546をACKしている)。] [0058] ACK552は、ACKがエア・インタフェースを横切らなければならなかった場合にユーザPC550によって生成されたACKが受信されたであろう時点よりもずっと早く、サーバにおいて受信される。これにより、プロキシ・ロジックが存在していなかった場合よりもずっと早くセグメント560が送出されることになる。このようにして、スループット性能は、TCPコネクションが、より短い時間の間、「遅い開始」状態にあるので、向上し、よって、RLCバッファは、満たされた状態に保たれる。] [0059] 更に、図5はダウンロードの場合を示しているが、本発明の一実施例では、効果的には、機能は、対称に実現することができるので、プロキシ機能は、アップロードについても同様に行われる。] 図5 [0060] 更に、プロキシ・ロジックは、修正されているが機能的なTCPスタックを利用するので、例えば、セグメントがコア・ネットワーク内で失われる時点を適切に検出することが可能である。当業者によって理解されるように、修正は事実上、前述の同期化しており、半トランスペアレントである(例えば、3ウェイ・ハンドシェイク及びデータ・セグメントを通す)機能である。それに応じて、プロキシ・ロジックは、適切な欠落パケットの、サーバによる再送信を要求する自己生成TCPACK(例えば、否定応答(NACK))で応答することができる。セグメントが失われた場合の同期化TCPプロキシの動作の例は後述する。] [0061] 次に図6を参照すれば、本発明の実施例による、TCPプロトコル・アクセラレータ・フロー制御600の動作を示す。ここでは、フロー制御を、UE又はRNCにおける無線リンク制御(RLC)バッファ610に関して示す。RLCバッファ610の概念図は、記憶されたデータで部分的に満たされた複数のバッファ612、614、616を示す。TCPフローに関連付けられた無線ベアラー(RB)毎のスペア・バッファ容量630は、各バッファの網掛けしていない領域620において示す。] 図6 [0062] 特定の同期化TCPプロキシからの「awnd」640は、個々のスペアRLCバッファ容量(同様に、このTCPフローがマッピングされているRBに関連付けられる)、及びRLCバッファ612、614、616全てに関連付けられたスペアRLCバッファ容量全体に関連付けられたスペア・バッファ占有量の関数に基づく。] [0063] よって、もう一度、図5を参照すれば、ネットワーク端におけるTCPプロキシがTCPACK552をサーバに送出すると、ACK内に含まれる「awnd」フィールドは上述した機能に基づいて算出される。] 図5 [0064] 一例では、「awnd」(何れの適切な関数でもよい)を算出する関数は、 awnd=Min(当初awnd,個々の空きバッファα,全体空きバッファβ) という形式のものであってよい。] [0065] 当初「awnd」は、3ウェイ・ハンドシェイクにおいてネゴシエートされた値である。「α」及び「β」の値は、経験的な定数値であり得る。] [0066] TCPプロトコル・アクセラレータ・ロジックの意図は、上り(UL)及び下り(DL)TCPトラフィックに対する改善をもたらすというものである。したがって、受信側及び送信側の同期化TCPプロキシ機能がUE及びRAN内で提供される。本発明の一実施例によれば、TCPプロトコル・アクセラレータ・ロジックは、PDCPに常駐するよう構成される。] [0067] 前述の同期化プロキシの特に効果的な特徴は、ネットワークの (i)コア・ネットワーク(すなわち、サーバと、ネットワーク端における同期化プロキシとの間)、 (ii)無線アクセス・ネットワーク(すなわち、RLC(及び/又はHARQ機能)によって補正することが可能でないエア・インタフェースにおける喪失を識別すること)、及び (iii)UEとPCとの間の接続 の部分の何れかにおいて失われたセグメントを扱うことができることである。] [0068] 前述の3つの場合のうちの1つ又は複数を扱うために、以下のバッファリング・ロジックを本発明の実施例において提供することができる。] [0069] (i)受信側のプロキシにおける、図7及び図8に関して後述するようなバッファリング・ロジック(適切な欠落セグメントが受信されるまで、順番でないセグメントを記憶することが可能であり、よって、上位層へのセグメントを順番に供給することが可能になる。更に、喪失された、コア・ネットワーク(又はUEとPCとの間のリンク)に送信されたセグメントを扱うために必要であるが、これは、プロキシに関連付けられたTCPスタック機能において固有であり、ここでは、それ以外は検討しない。] 図7 図8 [0070] (ii)バッファリング・ロジックは更に、送信側プロキシにおいても提供され得るので、補正されていない喪失が無線アクセス・ネットワークにおいて(例えば、エア・インタフェースにおける永続的なエラーにより、RLCにおいて生じたMRW又はリセットにより、)生じた場合、プロキシ・ロジックは、喪失されたセグメントを再送信することができる。] [0071] 次に図7を参照すれば、本発明の実施例による、同期化TCPプロキシ555、556において使用されるバッファ・ロジック機能700を示す。図7では、エア・インタフェース725を介して送出される対象の、RNC515によって受信されたデータ・セグメントが、RLCロジック715に入力される。同じデータ・セグメントは、このセグメントを構成するPDUの送出/再送出の、固定数の試行後に、ピアRLCエンティティからRNC515によって「ACK」が受信されない場合、記憶し、潜在的には、受信エンティティに再送信するために、送信バッファ705にも入力される。] 図7 [0072] SDUにおけるPDUの何れか1つが、最大のRLC PDU再送信可能回数に達した場合、RLCロジック715は断念し、MRWを送出し、SDUを構成するPDU全てを廃棄する。] [0073] MRW又はリセットがRNC515に示されると、送信バッファ705内の適切なデータ・セグメントが送出される(710)。RLCロジック715が、MRW/リセットの表示を受信し、セグメント内のPDU全てが首尾良く送出されると(720)、RLCロジック715は、(潜在的な再送信を待っている)記憶セグメントが削除されることを可能にする旨を送信バッファ705に通知する。] [0074] エア・インタフェース725の反対側では、UE510は、RNC515からデータ・セグメントを受信するためのRLCロジック750を含み、前述の受信データ・セグメントを受信バッファ・ロジック755に転送する。UE510は、図示するようなTCPプロキシ・ロジック555も備える。本発明の一実施例では、受信バッファ・ロジック755は、再配列ロジック(図示せず)に、動作可能に結合され得、主に、UE受信バッファ・ロジック755が、TCPエンドポイントへの順番通りの配信を確実にするよう構成されることを可能にするために導入される。] [0075] 図7のアーキテクチャの一動作は、受信器バッファ・ロジック755によって実現されるような、次に期待されるTCPシーケンス番号の維持に基づく。本発明の一実施例では、これは以下のように維持される。すなわち、 i. TCPシーケンス番号の当初値は、3ウェイ・ハンドシェイクにおいてネゴシエートされた値に基づいて設定することができる。] 図7 [0076] ii.セグメントが、受信器バッファ・ロジック755からサーバ(又はPC)に送出されると、次に期待されるシーケンス番号が、このセグメントにおけるTCPデータの容量だけ、増加させられる。] [0077] 本発明の例示的な実施例は、図8に示す形態の受信バッファ・ロジック755を利用する。この受信バッファ・ロジック755の構成は、以下の規則を追跡し得る: (i)セグメントは、受信されると、以下のようにセグメントのSEQに基づいて受信バッファ・ロジック755に入れられる。] 図8 [0078] a. 次に期待されるシーケンス番号に一致する場合、バッファ810の先頭に配置される。] [0079] b. 次に期待されるシーケンス番号に一致しない場合、SEQ順序820において別個にバッファリングされる。] [0080] (ii)セグメントは、バッファの先頭を占める場合、サーバ(又はPC)に送出される(815)。 (iii)バッファの先頭が空いている場合、バッファの先頭にセグメントを配置することが可能であるかを確かめるためにバッファの残りがサーチされる(次に期待されるセグメント番号は更新されている)。] [0081] このバッファ・ロジック機能の動作には、エア・インタフェースを介したTCPシーケンス番号(又はその圧縮バージョン)の送信が関係する。やはり、図3におけるアーキテクチャと違って、前述の実施例では、TCPプロトコルが実際に動作せず、それぞれのプロキシで終結されるが、エア・インタフェースを介してTCPヘッダ(又は少なくとも圧縮されたTCPヘッダ)が搬送される。] 図3 [0082] 送信同期化プロキシは更に、(ユーザPC又はサーバにおける)送信側TCPエンドポイントに早期ACKを供給するためのロジックを備える。よって、RLCエンティティが、(例えば、エア・インタフェースにおいて繰り返される障害により、)セグメントを送出することができない場合、同期化プロキシは、セグメントを再送信するよう構成される(TCPエンドポイントは、明らかに、ACKされているので、セグメントを再送信することが可能でない)。] [0083] 図8は更に、本発明の実施例による、同期化TCPプロキシの送信側850において使用されるバッファ機能を示す。TCPプロキシ556の送信側に入る各TCPセグメント855は送信バッファ・ロジック755に記憶される。図8に示すように、TCPACK75が、図5に関して前述したように生成される。] 図5 図8 [0084] セグメントを構成するPDU全て(セグメントは複数のRLC PDUを含み得る)が、受信側ピアRLCエンティティによってACKされているという旨の表示865が送信側RLCエンティティからあった場合に、セグメント870がこの送信バッファ・ロジック755から除去/削除される。] [0085] しかし、RLCMRW又はPLCリセットが生じた旨の表示875が送信側RLCエンティティから受信された場合、RLCによって廃棄されたセグメントは全て、RLCロジックに再送出される(880)。例えば、送信側エンティティは、正しく受信されているという肯定応答を受信側RLCエンティティから得ることなく、1つ又は複数のセグメントに対応するいくつかのRLCPDUの送出の試行を停止する。] [0086] 次に図9を参照すれば、セグメントがコア・ネットワーク内で失われた場合のプロトコル・アクセラレータの動作の例を示す。ネットワークは、UE及びネットワークにおいて同期化TCPプロキシ555及び556を備え、上記TCPプロキシは、既知の3ウェイ・ハンドシェイク(「SYN」、「SYNACK」及び「ACK」)が、PC505と、例えば、ウェブ・サーバ520との間のエンドツーエンド通信のためにトランスペラレントに通過することを可能にするよう構成される。] 図9 [0087] よって、前述のTCPメッセージに含まれる情報はその場合、当初、TCPコネクションがPC505とサーバ520との間の完全なエンドツーエンド接続であるということを確実にするために使用される。TCPプロキシは、3ウェイ・ハンドシェイクにおいて使用されるSEQ番号及びACK番号、並びに、ウィンドウ・スケーリング又は選択的な肯定応答などの、ネゴシエートされる何れかのオプションを観察する。このようにして、TCPプロキシは、プロキシ生成されたACK又は早期ACKが生成された場合、TCPコネクションの実際のエンドポイントが生成したであろうACKに(できる限り近く)一致する。] [0088] よって、効果的には、サーバ及びPCに関する限り、TCPが事実上、接続のエア・インタフェース部分を介して動作していなくても、TCPコネクションはなお、エンドツーエンド・リンクであるようにみえる。] [0089] この例では、3ウェイ・ハンドシェイクが既に行われており、プロキシが完全に同期化されているものとする。] [0090] 図示したように、「SEQ1000」及び「SEQ2000」はウェブ・サーバ520からPC505に送出される。周知の遅延ACK機能が動作しているものとし、通常、TCP ACKは、一TCPセグメントおきに送出される。よって、SEQ2000を備えたセグメントがネットワーク側プロキシ556においてみられた後、SEQ1000を備えたセグメント及びSEQ2000を備えたセグメントの正しい受信を肯定応答するTCP ACKが生成される(572)。ネットワーク側プロキシ556は、無線アクセス・ネットワーク内の低位層に前述のセグメントが送出されることを可能にし、これは、その後、UE555におけるプロキシを介してPC505に送出される。ACKがPC570によって生成される。しかし、このACKは、UE555におけるプロキシにおいて廃棄される。上記セグメントが、プロキシによって生成されたACK572によって既に肯定応答されているからである。] [0091] プロキシによって生成されたACK572を受信すると、サーバは、更に2つのセグメント(SEQ3000を備えたセグメント905及びSEQ4000を備えたセグメント910)を送出する。この例において示すように、SEQ3000を備えたセグメントはコア・ネットワークにおいて失われている。ネットワークにおけるプロキシは、TCPスタックの動作によって規定されるように通常のやり方で反応し、SEQ4000を備えたセグメントの受信を肯定応答するTCP ACK920で応答するが、更に、SEQ3000が受信されていない(これは、3ウェイ・ハンドシェイクにおいて、選択された肯定応答がネゴシエートされているものとする)旨を更に示す。] [0092] 一方、SEQ4000を備えたセグメントが、ネットワークにおいて通常として送出され、ポイント935のUEにおけるプロキシにおいて受信される。しかし、図9に表す機能は、このセグメントがPC505に転送されないが、バッファリングされるということを意味している。] 図9 [0093] TCPACK920が受信されると、サーバは、SEQ3000を備えたセグメントを再送信する(工程925)。これは次いで、ネットワーク側プロキシを介して送出され、最終的に、UEにおけるプロキシ・ロジックに達する。図9に表すバッファ/再配列ロジックにより、SEQ3000を備えたセグメント、及びそれに続く、(先行して記憶された)SEQ4000を備えたセグメントがユーザPCに向けて送出されることを確実にされる。] 図9 [0094] ユーザPCは次いで、セグメントSEQ3000及びSEQ4000の受信を肯定応答する応答590を送出する。効果的には、セグメントの順番通りの配信が維持される。これは次いで、UEにおけるプロキシにおいて廃棄される。] [0095] 図9と同様に、図10は、本発明の実施例による、(例えば、RLCが、RLCプロトコル・データ・ユニット(PDU)の最大再送信試行数に達し、よって、セグメント全体を廃棄することにより、)データ・セグメント「SEQ3000」1005がRANにおいて失われた場合の同期化TCPプロキシの動作の例を示す。] 図10 図9 [0096] ネットワークにおけるプロキシは、応答メッセージ1120で、セグメントSEQ3000及びSEQ4000に肯定応答する。その後、ネットワークにおける送信側RLCエンティティは、SEQ4000を備えたセグメントの送出を首尾良く行っていても、SEQ4000を備えたSEQ3000を備えたセグメントの送出の試行を断念する(1040参照)。] [0097] プロキシ・ロジックには、図10に記載した機能を使用して、メッセージ1030において再送信されるように、このセグメントについてMRWが生じた旨が通知される。UEにおける受信側プロキシでは、これは明らかに、SEQ4000を備えたセグメントが、SEQ3000を備えたセグメント前に受信されるということを明らかに表す。しかし、図9に表すケースにおけるように、図9に記載したバッファリング及び再配列ロジックは、SEQ4000を備えたセグメントがポイント1035で記憶されることを確実にする。] 図10 図9 [0098] SEQ3000を備えたセグメントは、UEにおけるプロキシにおいて受信されると、ユーザPCに送られ、続いて、SEQ4000を備えた記憶されたセグメントが続く。 図9及び図10と同様に、図11は、本発明の実施例による、データ・セグメント「SEQ3000」1105がUEプロキシ・ロジック555とクライアントPC505との間で失われた場合に、プロトコル・アクセラレータの動作の例を示す。] 図10 図11 図9 [0099] ここで、UEにおけるプロキシに関連付けられた標準的なTCPスタック機能は、セグメントが、UEにおけるプロキシと、ユーザPCとの間で失われた場合、SEQ3000を備えたセグメントが受信されていないが、SEQ4000を備えたセグメントがメッセージ1135において首尾良く受信されていることを示すTCPACKをユーザPC 505が送出した場合に、プロキシが、SEQ3000を備えたセグメントを再送信することによって応答するということを確実にする。] [0100] 特に、上述の例が示すように、エア・インタフェースの両方の端部におけるプロキシ・ロジックに導入される更なるロジックは、喪失が識別されると、実際の受信エンドポイントが実際にこのセグメントを受信する前に、TCPACKがプロキシから送出側に戻されるということを確実にする。] [0101] 本発明の一実施例は3GPPネットワークのエア・インタフェースの両方の端部においてプロキシ・ロジックを使用する概念を説明しているが、他の例では、本発明の概念は、将来の3GPPのロング・ターム・エボリューション(LTE)システムなどの、TCPを使用する何れかの他の通信システムに適用し得る。] [0102] 本発明の実施例は、以下の効果のうちの1つ又は複数をもたらすことを目的とする。] [0103] (i)再送信機能についてTCPに依存するのでなく、喪失パケットの高速再送信のためのRLCの使用 (ii)エア・インタフェースの両方の端部におけるプロキシ・ロジックの使用により、ACK、NACK同期化メッセージを送受信する必要性がなくなる。] [0104] 図12は、本発明の実施例における処理機能を実現するよう使用することができる通常のコンピューティング・システム1200を示す。このタイプのコンピューティング・システムは、例えば、GGSN、RNCなどのコア・ネットワーク・エレメント、ノードB(特に、ノードBのスケジューラ)において使用することができる。当業者は更に、他のコンピュータ・システム又はアーキテクチャを使用して本発明を実現する方法を認識するであろう。コンピューティング・システム1200は、例えば、特定のアプリケーション又は環境について望ましいか、又は適切であり得るデスクトップ、ラップトップ、ノートブック・コンピュータ、ハンドヘルド・コンピューティング装置(PDA、携帯電話機、パームトップ等)、メーンフレーム、サーバ、クライアント、又は何れかの他のタイプの専用又は汎用のコンピューティング装置を表し得る。コンピューティング・システム1200はプロセッサ1204などの1つ又は複数のプロセッサを含み得る。プロセッサ1204は、例えば、マイクロプロセッサ、マイクロコントローラや他の制御ロジックなどの汎用又は専用の処理エンジンを使用して実現することが可能である。この例では、プロセッサ1204は、バス1202又は他の通信媒体に接続される。] 図12 [0105] コンピューティング・システム1200は、プロセッサ1204によって実行される対象の命令及び情報を記憶するために、ランダム・アクセス・メモリ(RAM)や他のダイナミック・メモリなどの主メモリ1208も含み得る。主メモリ1208は、プロセッサ1204によって実行される対象の命令の実行中に一時変数や他の中間情報を記憶するために使用することもできる。コンピューティング・システム1200は同様に、プロセッサ1204の静的情報及び命令を記憶するために、バス1202に結合されたリード・オンリ・メモリ(ROM)や他の静的記憶装置を含み得る。] [0106] コンピューティング・システム1200は、情報記憶システム1210(例えば、メディア・ドライブ1212及び着脱可能な記憶インタフェース1220を含み得る)も含み得る。メディア・ドライブ1212は、ハード・ディスク・ドライブ、フロッピー(登録商標)・ディスク・ドライブ、磁気テープ・ドライブ、光ディスク・ドライブ、コンパクト・ディスク(CD)やディジタル・ビデオ・ドライブ(DVD)読み取り又は書き込みドライブ(R又はRW)や、他の着脱可能な、若しくは固定のメディア・ドライブなどの固定の、又は着脱可能な記憶媒体をサポートするためのドライブや他の機構を含み得る。記憶媒体1218は、メディア・ドライブ1212によって読み取られ、書き込まれる、例えば、ハード・ディスク、フロッピー(登録商標)・ディスク、磁気テープ、光ディスク、CD若しくはDVDや他の固定の、若しくは着脱可能な媒体を含み得る。前述の例が例証するように、記憶媒体1218は、特定のコンピュータ・ソフトウェア又はデータを記憶させたコンピュータ読み取り可能な記憶媒体を含み得る。] [0107] 別の実施例では、情報記憶システム1210は、コンピューティング・システム1200にコンピュータ・プログラムや他の命令又はデータのロードを可能にするための他の同様な構成部分を含み得る。前述の構成部分は例えば、着脱可能な記憶装置1218からコンピューティング・システム1200にソフトウェア及びデータを転送することを可能にする、着脱可能な記憶ユニット1222及びインタフェース1220(プログラム・カートリッジやカートリッジ・インタフェースなど)、着脱可能なメモリ(例えば、フラッシュ・メモリや他の着脱可能なメモリ・モジュール)及びメモリ・スロット、並びに他の着脱可能な記憶ユニット1222及びインタフェース1220を含み得る。] [0108] コンピューティング・システム1200は、通信インタフェース1224も含み得る。通信インタフェース1224は、コンピューティング・システム1200と外部装置との間でソフトウェア及びデータを転送することを可能にするために使用することが可能である。通信インタフェース1224の例には、モデム、ネットワーク・インタフェース(イーサネット(登録商標)や他のNICカードなど)、通信ポート(例えば、ユニバーサル・シリアル・バス(USB)ポートなど)、PCMCIAスロット及びカード等がある。通信インタフェース1224を介して転送されるソフトウェア及びデータの形式は、通信インタフェース1224によって受信することができる電子信号、電磁気信号、光信号や他の信号であり得る信号の形式である。前述の信号は、チャネル1228を介して通信インタフェース1224に供給される。このチャネル1228は、信号を搬送することができ、無線媒体、有線又はケーブル、光ファイバや他の通信媒体を使用して実現することができる。チャネルの特定の例には、電話回線、セルラ電話リンク、RFリンク、ネットワーク・インタフェース、ローカル・エリア・ネットワーク又はワイド・エリア・ネットワーク、及び他の通信チャネルを含む。] [0109] この文書では、「コンピュータ・プログラム・プロダクト」、「コンピュータ読み取り可能な媒体」等の語は、一般に、例えば、メモリ1208、記憶デバイス1218や記憶ユニット1222などの媒体を表すために使用され得る。コンピュータ読み取り可能な媒体の前述及び他の形態は、特定の動作をプロセッサに行わせるためにプロセッサ1204によって使用されるための1つ又は複数の命令を記憶し得る。前述の命令は、一般に、(コンピュータ・プログラムや他のグルーピングの形式にグループ化することができる)「コンピュータ・プログラム・コード」として表され、実行されると、本発明の実施例の機能をコンピューティング・システム1200が行うことを可能にする。符号は、直接、プロセッサに、特定の動作を行わせ、そうするようコンパイルさせ、かつ/又は、そうするための他のソフトウェア、ハードウェア、及び/若しくは、ファームウェア構成要素(例えば、標準機能を行うためのライブラリ)と組合せさせ得る。] [0110] 構成要素がソフトウェアを使用して実現される実施例では、ソフトウェアは、コンピュータ読み取り可能な媒体に記憶され、例えば、着脱可能な記憶ドライブ1212、ドライブ1212又は通信インタフェース1224を使用してコンピューティング・システム1200にロードされ得る。制御ロジック(この例では、ソフトウェア命令又はコンピュータ・プログラム・コード)は、プロセッサ1204によって実行されると、本明細書及び特許請求の範囲記載の本発明の機能をプロセッサ1204に行わせる。] [0111] 明瞭にする目的で、上記説明では、別々の機能的装置及びプロセッサを参照して本発明の実施例を説明している。しかし、別々の機能的装置、プロセッサ又は領域間の機能の何れかの適切な配分を、本発明から逸脱しない限り、使用することができるということが明らかになるであろう。例えば、別個のプロセッサ又はコントローラによって行うよう例証された機能は、同じプロセッサ又はコントローラによって行うことができる。よって、特定の機能装置への参照は単に、厳密な論理的又は物理的構造若しくは編成を示すよりも、前述の機能を提供するために適切な手段への参照としてみるものとする。] [0112] 本発明の局面は、ハードウェア、ソフトウェア、ファームウェア、又は前述の何れかの組み合わせを含む何れかの適切な形態で実現することができる。本発明は、任意的には、1つ又は複数のデータ・プロセッサ上及び/若しくはディジタル信号プロセッサ上で実行するコンピュータ・ソフトウェアとして少なくとも部分的に実現することができる。よって、本発明の実施例の構成要素及び構成部分は、何れかの適切なやり方で物理的、機能的、及び論理的に実現することができる。実際に、機能は、単一のユニットで実現しても、複数のユニットで実現しても、他の機能ユニットの一部として実現してもよい。] [0113] 本発明は、実施例に関して説明してきたが、本明細書及び特許請求の範囲記載の特定の形態に限定することを意図するものでない。むしろ、本発明の範囲は、特許請求の範囲によってのみ限定される。更に、特定の実施例に関して構成を説明しているようにみえることがあり得るが、本明細書及び特許請求の範囲記載の実施例の種々の構成を本発明によって組み合わせることができることを当業者は認識するであろう。] 実施例 [0114] 更に、個々に列挙しているが、複数の手段、構成要素又は方法工程を例えば、単一の装置又はプロセッサによって実現することができる。更に、個々の構成を別々の請求項に含めていることがあり得るが、これらは、場合によっては、組み合わせることが効果的であり得るものであり、別々の請求項に含めていることは、構成の組み合わせが実施可能でないこと及び/又は効果的でないことを示唆しているものでない。更に、請求項の一カテゴリに構成を含めていることは、このカテゴリへの限定を示唆するものでなく、むしろ、上記構成が、適宜、他のクレーム・カテゴリにも同様に適用可能であることを示している。 更に、請求項における構成の順序は、構成を行わなければならない何れかの特定の順序を示唆するものでなく、特に、方法クレームにおける個々の工程の順序は、工程をこの順序で行わなければならないことを示唆するものでない。むしろ、工程は、何れかの適切な順序で行うことができる。更に、単数形の参照は複数形を排除するものでない。よって、「a」、「an」、「第1の」、「第2の」等に対する参照は複数形を排除するものでない。]
权利要求:
請求項1 第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一端にある通信エンティティ(510、520)であって、前記通信エンティティは、前記第1のトランシーバ・エンティティと前記第2のトランシーバ・エンティティとの間の伝送制御プロトコル(TCP)通信をサポートするための通信ロジックと、受信セグメントを検査するためのプロキシ・ロジックとを備え、前記プロキシ・ロジックは、前記受信セグメントがデータを含んでいないことの識別に応じて、前記プロキシ・ロジックを介して前記第1のトランシーバ・エンティティと前記第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にするよう動作可能であり、前記プロキシ・ロジックは、前記複数の同期化セグメント及び前記受信セグメントに基づいて少なくとも1つの肯定応答メッセージを局所に生成するよう更に動作可能である通信エンティティ。 請求項2 請求項1記載の通信エンティティ(510,520)であって、前記プロキシ・ロジックは、後に受信されたセグメントがデータを含む場合に再同期化を行うよう更に動作可能であり、前記再同期化は、前記後に受信されたセグメントに含まれるシーケンス番号に基づく通信エンティティ。 請求項3 請求項2記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、データを含まない何れかの後の受信セグメントを却下するよう更に動作可能な通信エンティティ。 請求項4 請求項1乃至3の何れか一項に記載の通信エンティティ(510、520)であって、前記複数の同期化セグメントが3ウェイ・ハンドシェイクを備える通信エンティティ。 請求項5 請求項4記載の通信エンティティ(510、520)であって、前記3ウェイ・ハンドシェイクは、同期化表示(SYN542)、同期化肯定応答表示(SYNACK544)、及び肯定応答表示(ACK546)のうちの少なくとも1つを備える通信エンティティ。 請求項6 請求項1乃至5のうちの何れか一項に記載の通信エンティティ(510、520)であって、前記高レーテンシ通信リンクは無線データ通信システムのエア・インタフェースである通信エンティティ。 請求項7 請求項1乃至6の何れか一項に記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、受信ウィンドウ移動(MRW)、及びリセットのうちの一方が生じた時点を求めることにより、データ・セグメントの喪失を識別するための無線リンク制御ロジックを更に備える通信エンティティ。 請求項8 請求項7記載の通信エンティティ(510、520)であって、前記無線リンク制御ロジックは、バッファ・ロジックに、動作可能に結合され、前記バッファ・ロジックは、データ・セグメント全てが、無線リンクによって制御されており、RLCによって肯定応答されている旨を前記無線リンク制御ロジックが前記バッファ・ロジックに示すまで受信データ・セグメントを記憶するよう動作可能である通信エンティティ。 請求項9 請求項8記載の通信エンティティ(510、520)であって、前記バッファ・ロジックは、前記無線リンク制御ロジックからの表示に応じて、前記バッファ・ロジックのバッファから、前記肯定応答されたデータを廃棄するよう動作可能な通信エンティティ。 請求項10 請求項7乃至9の何れか一項に記載の通信エンティティ(510,520)であって、前記通信エンティティは、前記高レーテンシ通信リンクの受信側にあり、前記無線リンク制御ロジックは、前記無線リンク制御ロジックによって宣言されたMRW又はリセットにより、前記データ・セグメントのシーケンス番号全てが、首尾良く受信された訳でない場合に、欠落データを再送信する旨を要求するよう動作可能である通信エンティティ。 請求項11 請求項7乃至9の何れか一項に記載の通信エンティティ(510,520)であって、前記通信エンティティは前記高レーテンシ通信リンクの送信側にあり、前記無線リンク制御ロジックは、前記高レーテンシ通信リンクを介して送出された少なくとも1つのデータ・セグメントがMRW又はリセットを受けており、よって、前記受信側のRLCピア・エンティティで受信されておらず、前記バッファ・ロジックからの肯定応答されていないRLCデータ・セグメントの再送信をそれに応じて開始するよう動作可能である通信エンティティ。 請求項12 請求項1乃至11の何れか一項に記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、前記同期化セグメントを使用して正しく同期化された否定TCP応答(NACK)を局所的に生成するよう動作可能な通信エンティティ。 請求項13 請求項8乃至12の何れか一項に記載の通信エンティティ(510、520)であって、前記バッファ・ロジックは、前記複数の同期化セグメント内のシーケンス番号(SEQ)、肯定応答(ACK)番号、ウィンドウ・スケーリング、選択的肯定応答、及び、タイムスタンプのうちの少なくとも1つのメンテナンスを観察するよう動作可能な送信バッファ・ロジック及び受信バッファ・ロジックを備える通信エンティティ。 請求項14 請求項13記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、プロキシがない場合、受信側のエンティティによって実質的に生成されたであろうシーケンス番号(SEQ)、肯定応答(ACK)番号、ウィンドウ・スケーリング、選択的な肯定応答、及びタイムスタンプの以下のうちの少なくとも1つの観察されたメンテナンスに基づいて早期ACKメッセージを生成するよう動作可能である通信エンティティ。 請求項15 請求項13又は14に記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、前記ウィンドウ・スケーリングに基づいてACKメッセージ又はNACKメッセージにおいてシグナリングされるawnd値を受信するよう動作可能である通信エンティティ。 請求項16 請求項15記載の通信エンティティ(510、520)であって、前記プロキシ・ロジックは、バッファ占有量に基づいてawnd値を算出するよう動作可能な通信エンティティ。 請求項17 請求項1乃至16の何れか一項に記載の通信エンティティ(510、520)であって、前記TCPACKがデータを含まない旨を前記プロキシ・ロジックが判定することに応じて、前記高レーテンシ通信リンクを介して前記プロキシ・ロジックが、TCPACKを終結させ、前記TCPACKを送出しないよう動作可能な通信エンティティ。 請求項18 請求項1乃至17記載の通信エンティティ(510,520)であって、前記プロキシ・ロジックは、受信側のTCPエンティティがその個別のACKを送信する前にTCPACKを送信エンティティに戻すよう動作可能な通信エンティティ。 請求項19 請求項1乃至18の何れか一項に記載の通信エンティティ(510,520)であって、前記通信エンティティは、ユーザ機器(UE)、又はネットワーク・エンティティであり、前記通信ロジックは、第3世代パートナーシップ・プロジェクト(3GPP)データ通信システムを介してTCP通信を可能にする通信エンティティ。 請求項20 第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一端にある通信エンティティ(510、520)における伝送制御プロトコル(TCP)通信をサポートするためのプロキシ・ロジックであって、受信セグメントを検査するための検査ロジックであって、前記受信セグメントがデータを含まないということの識別に応じて、前記検査ロジックが、前記プロキシ・ロジックを介して前記第1のトランシーバ・エンティティと前記第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にするよう動作可能である検査ロジックと、前記複数の同期化セグメント、及び前記受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージを生成するための肯定応答ロジックとを備えるプロキシ・ロジック。 請求項21 データ通信システムにおける第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の高レーテンシ通信リンクの一端にある通信エンティティにより、伝送制御プロトコル(TCP)通信を提供する、コンピュータによって可能にされる方法であって、受信セグメントをTCPプロキシ・ロジックによって検査する工程と、前記受信セグメントがデータを含まないとの判定に応じて、前記プロキシ・ロジックを介して前記第1のトランシーバ・エンティティと前記第2のトランシ—バ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にする工程と、前記複数の同期化セグメント及び前記受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージを前記プロキシ・ロジックによって局所に生成する工程とを備える方法。 請求項22 高レーテンシ通信リンクの一端にあり、第1のトランシーバ・エンティティと第2のトランシーバ・エンティティとの間の伝送制御プロトコル(TCP)通信をサポートする通信エンティティを備えるデータ通信システムであって、前記データ通信システムは、前記通信エンティティにあるプロキシ・ロジックを備え、前記プロキシ・ロジックは、受信セグメントを検査するよう動作可能であり、前記受信セグメントがデータを含まないということの識別に応じて、前記プロキシ・ロジックを介して前記第1のトランシーバ・エンティティと前記第2のトランシーバ・エンティティとの間を複数の同期化セグメントが通過することをトランスペアレントに可能にするよう動作可能であり、前記プロキシ・ロジックは、前記複数の同期化セグメント、及び前記受信セグメントの少なくとも一方に基づいて少なくとも1つの肯定応答メッセージを局所に生成するよう更に動作可能であるデータ通信システム。
类似技术:
公开号 | 公开日 | 专利标题 EP3075138B1|2020-08-12|Tcp traffic adaptation in wireless systems JP5786071B2|2015-09-30|通信システムにおける方法および装置 JP6025880B2|2016-11-16|Data transmission method, apparatus and system Raiciu et al.2012|How hard can it be? designing and implementing a deployable multipath {TCP} CN104025525B|2017-12-05|用于发送分组的方法和设备以及交换机装置 KR101594304B1|2016-02-16|무선 통신 네트워크에서 다중경로 전송 접속을 위한 동적 서브플로우 제어 Ludwig et al.2000|The Eifel algorithm: making TCP robust against spurious retransmissions Fairhurst et al.2002|Advice to link designers on link Automatic Repeat reQuest | US9860915B2|2018-01-02|Apparatus and method for moving a receive window in a radio access network EP2887595B1|2019-09-11|Method and node for retransmitting data packets in a tcp connection FI110831B|2003-03-31|Menetelmä tiedonsiirron tehostamiseksi ja tiedonsiirtoprotokolla US7804780B2|2010-09-28|Receiving and transmitting devices for providing fragmentation at a transport level along a transmission path AU764700B2|2003-08-28|Packet discard notification for semi reliable retransmission protocol US7742419B2|2010-06-22|Method, system and article for improved TCP performance during packet reordering EP1698087B1|2016-01-20|Transparent optimization for tcp flow control AU2005253495B2|2008-01-17|Transmitting and receiving control protocol data unit having processing time information US6301249B1|2001-10-09|Efficient error control for wireless packet transmissions JP3677297B2|2005-07-27|階層arq方式のための連結された誤り検出コード化及びパケット番号付け KR101387537B1|2014-04-21|성공적으로 수신했으나 헤더 압축 복원에 실패한 패킷의 처리 방법 US7397800B2|2008-07-08|Method and system for data placement of out-of-order | TCP segments US6694471B1|2004-02-17|System and method for periodic retransmission of messages US7411959B2|2008-08-12|System and method for handling out-of-order frames ES2610396T3|2017-04-27|Un esquema de segmentación flexible para sistemas de comunicación CA2646512C|2011-07-12|Communication device and method US6757248B1|2004-06-29|Performance enhancement of transmission control protocol | for wireless network applications
同族专利:
公开号 | 公开日 EP2253176A1|2010-11-24| US8320250B2|2012-11-27| EP2253176B1|2017-04-05| JP5523350B2|2014-06-18| CN102007812A|2011-04-06| WO2009101004A1|2009-08-20| KR20100127760A|2010-12-06| US20090201813A1|2009-08-13| CN102007812B|2015-11-25|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
法律状态:
2012-01-31| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120130 | 2012-01-31| A621| Written request for application examination|Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120130 | 2012-08-14| A711| Notification of change in applicant|Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20120813 | 2012-12-19| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121218 | 2013-03-19| A601| Written request for extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20130318 | 2013-03-27| A602| Written permission of extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20130326 | 2013-05-23| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130522 | 2013-06-26| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130625 | 2013-09-12| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130911 | 2014-02-28| TRDD| Decision of grant or rejection written| 2014-03-12| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140311 | 2014-04-17| A61| First payment of annual fees (during grant procedure)|Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140408 | 2014-04-18| R150| Certificate of patent or registration of utility model|Ref document number: 5523350 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 | 2017-04-04| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2018-04-10| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2019-04-09| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2020-03-30| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2021-04-02| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
优先权:
[返回顶部]
申请号 | 申请日 | 专利标题 相关专利
Sulfonates, polymers, resist compositions and patterning process
Washing machine
Washing machine
Device for fixture finishing and tension adjusting of membrane
Structure for Equipping Band in a Plane Cathode Ray Tube
Process for preparation of 7 alpha-carboxyl 9, 11-epoxy steroids and intermediates useful therein an
国家/地区
|